Backup Strategies

Introduction

Backups protect against deletion, corruption, hardware failure, ransomware, and operational mistakes. In self-hosted environments, a backup strategy should cover both data and the information needed to restore services correctly.

Purpose

This guide covers:

• What to back up
• How often to back it up
• Where to store copies
• How to validate restore readiness

Architecture Overview

A good strategy includes:

• Primary data backups
• Configuration and infrastructure backups
• Off-site or offline copies
• Restore testing

The 3-2-1 rule is a strong baseline:

• 3 copies of data
• 2 different media or storage systems
• 1 copy off-site

For higher assurance, also consider an immutable or offline copy and zero-error verification.

Step-by-Step Guide

1. Inventory what matters

Back up:

• Databases
• Application data directories
• Compose files and infrastructure code
• DNS, reverse proxy, and secrets configuration
• Hypervisor or VM backup metadata

2. Choose backup tools by workload

• File-level backups: restic, Borg, rsync-based workflows
• VM backups: hypervisor-integrated backup jobs
• Database-aware backups: logical dumps or physical backup tools where needed

3. Schedule and retain intelligently

Use a retention policy that matches recovery needs. Short retention for frequent snapshots and longer retention for off-site backups is common.

4. Test restores

Backups are incomplete until you can restore and start the service successfully.

Configuration Example

Restic backup example:

export RESTIC_REPOSITORY=/backup/restic
export RESTIC_PASSWORD_FILE=/run/secrets/restic_password
 
restic backup /srv/app-data /srv/compose
restic snapshots

Example restore check:

restic restore latest --target /tmp/restore-check

Troubleshooting Tips

Backups exist but restores are incomplete

• Confirm databases were backed up consistently, not mid-write without support
• Verify application config and secret material were included
• Check permissions and ownership in the restored data

Repository size grows too quickly

• Review retention rules and pruning behavior
• Exclude caches, transient files, and rebuildable artifacts
• Split hot data from archival data if retention needs differ

Backups run but nobody notices failures

• Alert on backup freshness and last successful run
• Record the restore procedure for each critical service
• Test restores on a schedule, not only after incidents

Best Practices

• Back up both data and the configuration needed to use it
• Keep at least one copy outside the main failure domain
• Prefer encrypted backup repositories for off-site storage
• Automate backup jobs and monitor their success
• Practice restores for your most important services first

References

• restic documentation
• BorgBackup documentation
• Proxmox VE Backup and Restore